Settings for the fail page (callback_fail)

General requirements

  • Callbacks often fail because of caching services. You should disable caching services like CloudFlare, Varnish, etc.
  • All image, link, stylesheet, and form elements must use double quotes for attributes. For example

    <img href="image.png"/>
  • To prevent fraud attempts, the callback page must not accept traffic from any source but AltaPay's gateway. AltaPay's outgoing IP address is 185.206.120.0/24(ipv6: 2a10:a200::/29). You can do this, for example, using the following .htaccess file: 

    order deny,allow

    deny from all

    allow from <valid outgoing IP address>

  • Encode the page using UTF-8, or use HTML entities.
  • The maximum size for resources, for example, HTML, images, or CSS Files is 2 MB.

  • Resources must have the appropriate content type. See Supported Resource Content Types.
  • Verify that all parameters posted to the callback page are accurate to ensure that a fraud attempt has not been made.

  • Callback URLs must only use ports 443 and 80.

Specific requirements (callback_fail)

  • The FAIL-page should display an error message, and optionally allow the user to go back to the payment form (See Checkout link). Our payment gateway can handle multiple payments for the same order.

  • Both the FAIL- and the OK-page should display the content of the error_message field, if the cardholder_message_must_be_shown field has the value true.

  • The page must not contain a form for submitting the credit card info again.
  • If a payment fails, you can re-use the same payment request, for example, by redirecting your customer to the URL you received from the call to createPaymentRequest. Note that certain payment providers only allow a limited number of attempts. For more information, see Payment methods and providers.

  • In case of success the http response code should be 200, or if you want us to redirect the user 301, 302, 303 or 307.

Evaluate status of the payment

There are cases in which the callback fail will be triggered even thought the payment has been successful. For example:
  • The user has refreshed the browser, and we are not able to load the cached response from the callback_ok, either because you system did not return the right response, or due to lack of availability of the cache

  • An internal error has ocurred, that disallowed for the flow to be completed, even though the payment has finished successfully.

In order to identify whether the payment is indeed successful, then you should check the `ReservedAmount` in the callback:
  • When the ReservedAmount > 0, the system was able to process the transaction successfully.

  • When the ReservedAmount = 0 | null, the system was not able to process the transaction successfully.

It is important to ensure that the reserved amount has a match with what you expect when initially processing the payment.